This section describes control tables that are used throughout your product.
Contents
Support For Different Languages
Setting Up Characteristic Types & Values
Setting Up Foreign Key Reference Information
Defining Feature Configurations
Defining Master Configurations
The topics in this section describe the various installation options that control various aspects of the system.
Contents
Installation Options - Messages
Installation Options - Algorithms
Installation Options - Accessible Modules
Installation Options - Installed Products
Select Admin Menu, Installation Options, Installation Options - Framework to define system wide installation options.
Description of Page
The Environment ID is a unique universal identifier of this instance of the system. When the system is installed, the environment id is populated with a six digit random number. While it is highly unlikely that multiple installs of the system at a given implementation would have the same environment ID, it is the obligation of the implementers to ensure that the environment ID is unique across all installed product environments.
System Owner will be Customer Modification.
The Admin Menu Order controls how the various control tables are grouped on the Admin Menu.
· If you choose Alphabetical, each control table appears under a menu item that corresponds with its first letter. For example, the Language control table will appear under the L menu item entry.
· If you choose Functional, each control table appears under a menu item that corresponds with its functional area. For example, the Language control table will appear under the General menu item entry. Note, the menu that is used when this option is chosen is the sole menu identified with a menu type of Admin.
Warning! In order to improve response times, installation options are cached the first time they are used after a web server is started. If you change the Admin Menu Order and you don't want to wait for the cache to rebuild, you must clear the cached information so it will be immediately rebuilt using current information. Refer to Caching Overviewfor information on how to clear the system login cache (this is the cache in which installation options are stored).
The Language should be set to the language in which you work.
The Currency Code is the default currency code for transactions in the product.
If your product supports characteristics on its objects, define the date to be used as the Characteristic Default Date on objects without an implicit start date. The date you enter in this field will default when new characteristics are added to these objects (and the default date can be overridden by the user).
Active Owner displays the owner of newly added system data (system data is data like algorithm types, zone types, To Do types, etc.). This will be Customer Modification unless you are working within a development region.
Country and Time Zone represent the default country and time zone that should be used throughout the application.
Turn on Seasonal Time Shift if your company requires seasonal time shift information to be defined. Refer to The Big Picture of Time Options for more information.
Select Admin Menu, Installation Options, Installation Options - Framework and the Messages tab to review or enter messages that will appear throughout the application when a given event occurs.
The Message collection contains messages that are used in various parts of the system. For each message, define the Installation Message Type and Installation Message Text. The following table describes how the various Message Types are used in the system.
|
Message Type |
How The Message Is Used |
|
Company Title for Reports |
This message appears as a title line on the sample reports provided with the system. Generally it is your company name. It is only used if you have installed reporting functionality and are using the sample reports (or have designed your reports to use this message). |
Select Admin Menu, Installation Options, Installation Options - Framework and the Algorithms tab to review or enter the algorithms that should be evoked when a given event occurs.
The grid contains Algorithms that control important functions in the system. You must define the following for each algorithm:
· Specify the System Event with which the algorithm is associated (see the table that follows for a description of all possible events).
· Specify the Sequence Number and Algorithm for each system event. You can set the Sequence Number to 10 unless you have a System Event that has multiple Algorithms. In this case, you need to tell the system the Sequence in which they should execute.
Warning! These algorithms are typically significant processes. The absence of an algorithm might prevent the system from operating correctly.
The following table describes each System Event.
|
System Event |
Optional / Required |
Description |
|
Global Context |
Optional |
Algorithms of this type are called whenever the value of one of the global context fields is changed. Algorithms of this type are responsible for populating other global context values based on the new value of the field that was changed. Refer to Global Context Overview for more information. Click here to see the algorithm types available for this system event. |
|
Next To Do Assignment |
Optional |
This type of algorithm is used to find the next To Do entry a user should work on. It is called from the Current To Do dashboard zone when the user ask for the next assignment. Click here to see the algorithm types available for this system event. |
|
Reporting Tool |
Optional |
If your installation has integrated with a third party reporting tool, you may wish to allow your users to submit reports on-line using report submission or to review report history online. This algorithm is used by the two on-line reporting pages to properly invoke the reporting tool from within the system. Click here to see the algorithm types available for this system event. |
|
To Do Pre-creation |
Optional |
These types of algorithms are called when a To Do entry is being added. Click here to see the algorithm types available for this system event. |
|
To Do Information |
Optional |
We use the term To Do information to describe the basic information that appears throughout the system to describe a To Do entry. Plug an algorithm into this spot to override the system default “To Do information”. Click here to see the algorithm types available for this system event. |
Select Admin Menu, Installation Options, Installation Options - Framework and the Accessible Modules tabto view the list of accessible modules.
Description of Page
This page displays the full list of the application's function modules. A Turned Off indication appears adjacent to a module that is not accessible based on your system's module configuration setup.
Refer to Module Configuration for more information on function modules and how to turn off modules that are not applicable to your organization.
Select Admin Menu, Installation Options, Installation Options - Framework and the Installed Products tab to view a read only summary of the products that are installed in the application version that you are logged into.
Description of Page
The Product Name indicates the name of the "products" that are installed. The collection should include Framework, an entry for your specific product and an entry for Customer Release.
Release ID shows the current release of the application that is installed. This field is used by the system to ensure that the software that executes on your application server is consistent with the release level of the database. If your implementation of the product has developed implementation-specific transactions, you can populate the Release Id for the Customer Release entry to define the latest release of implementation-specific logic that has been applied to this environment. In order for this to work, your implementation team should populate this field as part of their upgrade scripts.
The Release ID Suffix, Build Number and Patch Number further describe the details of your specific product release.
The Display column indicates the product whose name and release information should be displayed in the title bar. Only one product sets this value to Yes.
Owner indicates if this entry is owned by the base package or by your implementation (Customer Modification).
About Information. The information on this tab is used to populate the information displayed in the About information for your product.
Contents
The system provides support for multiple languages in a single environment. System users can use the system in their preferred language, as long as a translation into that language has been provided. By default, a user sees the system in their default language (which is defined on their user record). Also note, if enabled, users can use the Switch Language Zone to switch to another supported language real time.
Note: Normally, setting up the system for another language is an implementation issue, not an administrative set-up issue. However, there are several on-line administrative features that are used to set up a new language, and these are described here.
The following steps are required to support a new language.
· Define a language code. Refer to Defining Languages for more information.
· Copy descriptions of all language enabled tables from an existing translation. For example, you might copy existing English language translations. These copied values are not meant to be used by system users, but act merely as “placeholders” while they are being translated into the new language. It is necessary to do this as a first step in order to create records using the new language code created in the previous step.
Language based descriptions can be copied using a supplied batch process, NEWLANG.
· Assign the new language code to your User ID, sign out, and sign back in again. Any on-line functions that you access will use your new language code. (You can change the language code for all users who plan to use/modify the new language).
· Begin translations. You might start with screen labels, menus, look-up values, and error messages. On-line utilities have been provided to give you access to this system data. Refer to User Interface Tools and Database Tools for more information. All administrative control tables are language enabled as well. The descriptions (short descriptions, long descriptions, etc.) are all translatable.
Your product may support additional uses for language. For example, in Oracle Utilities Customer Care and Billing, you can define each customer's language. This allows you to send bills and other correspondence in each customer's preferred language. For more information, navigate to the index entry Languages, Customer Language.
A language code exists for every language spoken by your users. The system uses this code to supply information to users in their respective language. Select Admin Menu, Language to define a language.
Description of Page
Enter a unique Language Code and Description for the language.
Turn on Language Enable if the system should add a row for this language whenever a row is added in another language. For example, if you add a new currency code, the system will create language specific record for each language that has been enabled. You would only enable multiple languages if you have users who work in multiple languages.
The following two fields control how the contents of grids and search results are sorted by the Java virtual machine (JVM) on your web server:
· The Locale is a string containing three portions:
· ISO language code (lower case, required)
· ISO country code (upper case, optional)
· Variant (optional).
Underscores separate the various portions, and the variant can include further underscores to designate multiple variants. The specific JVM in use by your particular hardware/OS configuration constrains the available Locales. Validating the Locale against the JVM is outside the scope of this transaction. This means you are responsible for choosing valid Locales.
The following are examples of valid locales:
· en_US (this is for American English)
· en_AU (this is for Australian English)
· pt_BR (this is for Brazilian Portuguese)
· fr_FR_EURO (this is for European French)
· ja_JP (this if for Japanese)
In addition, the Java collation API can take a Collator Strength parameter. This parameter controls whether, for example, upper and lower-case characters are considered equivalent, or how accented characters are sorted. Valid values for collator strength are PRIMARY, SECONDARY, TERTIARY, and IDENTICAL. If you leave this field blank, Java will use its default value for the language. We’d like to stress that the impact of each value depends on the language.
Please see http://java.sun.com/j2se/1.3/docs/guide/intl/locale.doc.html for more information about the collator strength for your language.
Display Order indicates if this language is written Left to Right or Right to Left.
Owner indicates if this language is owned by the base package or by your implementation (Customer Modification). The system sets the owner to Customer Modification when you add a language. This information is display-only.
Where Used
Follow this link to open the data dictionary where you can view the tables that reference CI_LANGUAGE.
Note that all administrative control tables and system metadata that contain language-specific columns (e.g., a description) reference a language code.
In addition, other tables may reference the language as a specific column. For example, on the User record you indicate the preferred language of the user.
The topics in this section describe how to maintain countries.
Contents
To add or review Country definitions choose Admin Menu, Country.
The Main page is used to customize the fields and field descriptions that will be displayed everywhere addresses are used in the system. This ensures that the all addresses conform to the customary address format and conventions of the particular country you have defined.
Description of Page
Enter a unique Country and Description for the country.
The address fields that appear in the Main page are localization options that are used to customize address formats so that they conform to address requirements around the world. By turning on an address field, you make that field available everywhere addresses for this country are used in the system. You can enter your own descriptions for the labels that suffix each switch; these labels will appear wherever addresses are maintained in the system.
Where Used
Follow this link to open the data dictionary where you can view the tables that reference CI_COUNTRY.
To maintain the states located in a country, choose Admin Menu, Country and navigate to the State page.
Description of Page
Use the State collection to define the valid states in the Country.
· Enter the standard postal abbreviation for the State or province.
· Enter a Description for this state or province.
The currency page allows you to define display options related to currency codes that are used by your system. Use Admin Menu, Currency Code to define the currency codes in which financial information is denominated.
Description of Page
Enter a unique Currency and Description for the currency.
Use Currency Symbol to define the character that prefixes currency amounts in the system (e.g., $ for U.S. dollars).
Enter the number of Decimals that will appear in the notation for the currency. For example, there are two decimal positions for Australian dollars ($5.00), but no decimal positions in the Italian lira (500 L).
The Currency Position indicates whether the currency symbol should be displayed as a Prefix or a Suffix to the currency amount. For example, the US Dollar symbol is a prefix before the amount ($5.00) and the French franc symbol is a suffix after the amount (200.00FF).
Where Used
Follow this link to open the data dictionary where you can view the tables that reference CI_CURRENCY_CD.
This section highlights functionality provided to help an implementation manage date and time data for customers or employees cross multiple time zones as well as managing time sensitive data affected by legal time vs. standard time.
Contents
The Big Picture Of Time Options
There are many implementations that will not need to define time options. The following are some examples of implementations that require time option configurations:
· Interval billing. For customers with data being stored for every hour or every half hour or every fifteen minutes, the date and time stamp recorded for this data is very important. Logic must cater for customers in a different time zone than the system server. And logic must cater for the twice-yearly shift between winter and summer time.
For more detailed information, refer to the Oracle Utilities Customer Care and Billing section Interval Billing / Time Zone and Time Changes.
Note. Not all implementations with interval billing customers require time option configuration. If ALL your customers reside in the same time zone AND your region does not observe any time shift, you do not need to configure time options.
· Time sensitive data for reporting purposes. Consider this scenario, at 10am a customer in the US Eastern time zone reports an outage to their utility company whose server resides in the US Central time zone (-1 hour). The reported outage time is recorded with the system's time of 9am. When a field worker is dispatched to restore the service, the field worker is also in the Eastern time zone. The implementation may choose to translate the "outage reported" time to the field worker's time zone. (This is a business decision). The field worker records when the service is restored with a date time stamp. For reporting purposes, this date/time should be stored in the system with the same time zone as the system time. So if the field worker's computer stamped Eastern time (for example 11am), the information must be translated to Central time when passing the information back to the server to read 10am. That way, when reporting is done, the elapsed time between the outage being reported and being restored is accurate (1 hour).
In this example you must also consider the seasonal time shift schedule. For many regions the shifting from summer time to winter time (and back again) occurs in all areas and at the same time. However, there are some regions where a portion of the area does not shift time at all. (For example, the state of Arizona in the US.) Or where the schedule for shifting is at a different time. (For example, the state of Tasmania in Australia changes their clocks to summer time a few weeks earlier than the rest of the country.)
Implementation specific. Note that the product does not provide any time adjustment logic for integration with an external system as described in the above example. Rather, the product provides the configuration tables that your implementation would use to support this logic.
In general, the system default is that all date / time fields stored in the database are recording the "legal" time. In other words, in the winter it is recording standard time and in the summer it is recording the shifted time.
However, you may configure the database to indicate that one or more date/time fields on a given table should record the data in standard time.
When indicating that date / time fields on a table should record data in standard time, you must consider which individual date / time fields are storing logical time verses a physical server time. Consider interval data tables in the Oracle Utilities Customer Care and Billing product as a case study. There are two types of date / time fields stored on entities that capture interval data:
· System time stamp fields: these represent the effective date and time of the data and are typically stamped with the system time on the server, for example the date / time that data was received from an external system.
· Interval time fields: these are the actual interval date and time representing interval values, such as prices, quantities or time of use values. The system refers to these as logical time fields or times related to business functionality.
The system does not assume that the server and all the data related to business functionality observe the same seasonal time shift.
· Your server typically observes time shifts associated with the local time zone.
· Although time related to business functionality are likely to also observe the time shift for the local time zone, there may be situations where data is not displayed in legal time. For example, perhaps your data related to interval prices are always displayed in standard time (and the users know this).
The following points describe how to define seasonal time shifting information:
· Use the Seasonal Time Shift page to define the schedule of shifting into and out of standard time. Refer to Designing Seasonal Time Shift for more information.
· Link the seasonal time shift record, which contains the time shift schedule used for the server, to the base time zone on the installation record. In addition, for each time zone you define, you should indicate its seasonal time shift schedule as well. Refer to Designing Time Zones for more information.
· For each entity that includes a field that captures "logical" time, an appropriate configuration table should be designed to include seasonal time shift as a foreign key.
· The user interface that displays data captured in standard time should support the ability to toggle between standard and legal time using the appropriate seasonal time shift information as define above.
Note. If a time zone or a particular entity type related to business functionality does not observe a time shift, the seasonal time shift record linked to the entity contains no schedule of the shift. Refer to Designing Seasonal Time Shift for more information.
The following sections describe how to configure your time options in the system.
The Seasonal Time Shift object records the dates and times that a time zone will switch between standard time and a seasonal time change. All data is stored in standard time. You will only need to define seasonal time shifts if
· Areas, where your company and your customers operate shift their clocks for seasonal changes
· Business practices such as the examples provided in The Big Picture of Time Options require your company to interrogate this information.
If your company requires this information, you must check the Seasonal Time Shift switch on the installation options.
When designing your seasonal time shift, first you need to design an entry that represents no shifting. This may be used by areas in your service territory, where time is not shifted for seasonal changes. It may also be used by entities, which are always stored in standard time, for example contract data such as TOU map data in Oracle Utilities Customer Care and Billing.
Next, you need to look at where your company operates, and the schedule of time shifting the various locations follow.
Let’s consider a company that operates totally in the United States. In addition to the “no shifting” entry, only one seasonal time shift entry is required because all areas, which observe daylight savings time, change their clocks on the same date and time. For each date and time entry, you must indicate the change from the standard time. In the US example, the spring change shifts by 60 minutes and the autumn change shifts by 0 minutes (because time is returning to standard time).
You must also consider the time that time shifts. In the US, the shift from Standard time to Daylight Savings time (in April) occurs at 02:00 shifting the legal time to 03:00. In other regions around the world, this shift may occur at 01:00 or at 00:00 or even at 22:00. In the US, the shift from Daylight Savings time to Standard time (in October) occurs at 02:00 legal time, shifting back to the standard time 01:00. In this case, the standard time of the shift takes place at 01:00.
|
Seasonal Time Shift |
Description |
Shift Effective Date |
Shift in Minutes |
|
NoShift |
No shifting |
|
|
|
USShift |
Daylight Savings Time |
19 / Apr / 2000 02:00 |
60 |
|
29 / Oct / 2000 01:00 |
0 |
||
|
1 / Apr / 2001 02:00 |
60 |
||
|
28 / Oct / 2001 01:00 |
0 |
||
|
7 / Apr / 2002 02:00 |
60 |
||
|
27 / Oct / 2002 01:00 |
0 |
If a company operates in other areas, where time changes for seasons are done on different dates and times, then additional seasonal time shift records are required. Let’s consider Australia’s time shifting schedule. In Australia
· A majority of regions follow the shifting schedule of daylight savings time starting on the last Sunday in October at 02:00 and returning to standard time on the last Sunday in March at 03:00 legal time (returning to 02:00 standard time).
· The state of Tasmania starts daylight savings time on the first Sunday in October, rather than the last.
· Some regions do not change their time for seasonal shifts at all. We have already designed the NoShift entry above.
|
Seasonal Time Shift |
Description |
Shift Effective Date |
Shift in Minutes |
|
Tasmania |
Daylight Savings Time |
25 / Mar / 2001 02:00 |
0 |
|
7 / Oct / 2001 02:00 |
60 |
||
|
31 / Mar / 2002 02:00 |
0 |
||
|
6 / Oct / 2002 02:00 |
60 |
||
|
30 / Mar / 2003 02:00 |
0 |
||
|
5 / Oct / 2003 02:00 |
60 |
||
|
AusStd |
Daylight Savings Time |
25 / Mar / 2001 02:00 |
0 |
|
28 / Oct / 2001 02:00 |
60 |
||
|
31 / Mar / 2002 02:00 |
0 |
||
|
27 / Oct / 2002 02:00 |
60 |
||
|
30 / Mar / 2003 02:00 |
0 |
||
|
26 / Oct / 2003 02:00 |
60 |
It is recommended that all data is stored in the time of the base time zone as defined on the installation options. This will prevent any confusion when analyzing data and will ensure that your algorithms do not have to perform any shifting of data that may be stored in different time zones.
The Time Zone entity is used to define all the time zones where your customers may operate. It will be used by interfaces to help ensure data is stored in the base time zone.
When designing your time zones, the first thing to determine is the base time zone. For an example, let’s assume that your company’s main office is in the US Central time zone. First, you need to define this time zone and define the seasonal time shift whose schedule it follows.
|
Time Zone |
Description |
Shift in Minutes (from base time zone) |
Seasonal Time Shift |
|
USCentral |
Central Standard Time |
0 |
USShift |
Once this is done, you can link the time zone code to the installation option as the base time zone. Refer to Installation Options - Main for more information.
Now, you can define the other time zones where you may have customers or other systems with which you exchange data. Let’s use the US time zones as an example. We’ll define time zones for Eastern, Mountain, Pacific and one for Arizona, which doesn’t observe daylight savings time.
|
Time Zone |
Description |
Shift in Minutes (from base time zone) |
Seasonal Time Shift |
|
USCentral |
Central Standard Time |
0 |
USShift |
|
USEastern |
Eastern Standard Time |
60 |
USShift |
|
USMountain |
Mountain Standard Time |
-60 |
USShift |
|
USArizona |
Arizona Standard Time |
-60 |
NoShift |
|
USPacific |
Pacific Standard Time |
-120 |
USShift |
Let’s continue with the Australia example (assuming that our sample company based in US central time has business in Australia). Australia has the following time zone considerations:
· New South Wales, Victoria and ACT are in the Eastern time zone (GMT +10) and observe the standard seasonal time shifting schedule.
· Tasmania is in the Eastern time zone (GMT +10) and observes its own time shifting schedule.
· Queensland is in the Eastern time zone (GMT +10) and does not shift for seasonal changes.
· South Australia and Northern Territory are in the Central time zone (GMT +9.5) and observe the standard seasonal time shifting schedule.
· Western Australia is in the Western time zone (GMT +8) and does not shift for seasonal changes.
For our example, we will continue to enter the shift in minutes from US central time’s standard time.
|
Time Zone |
Description |
Shift in Minutes (from base time zone) |
Seasonal Time Shift |
|
AUSEST |
Australia Eastern Standard Time (NSW, ACT, VIC) |
960 |
AusStd |
|
Tasmania |
Tasmania (Eastern Standard Time) |
960 |
Tasmania |
|
Queensland |
Queensland (Eastern Standard Time) |
960 |
NoShift |
|
AUSCST |
Australia Central Std Time (SA, NT) |
930 |
AusStd |
|
WesternAUS |
Western Australia |
840 |
NoShift |
The following sections describe the pages where time option configurations are entered.
Contents
Setting Up Seasonal Time Shift
Open Admin Menu, Seasonal Time Shift to define the seasonal time shift schedule.
Description of Page
Enter a unique Seasonal Time Shift code and Description for the seasonal time shift.
The Collection defines the Effective Date/Time (in standard time) that a time zone may shift in and out of standard time. If time is changed from standard time on the effective date/time, enter the Shift in Minutes that the time changes from standard time (usually 60). If the time is changed back to standard time on the effective date/time, enter a Shift in Minutes of 0.
Where Used
Follow this link to open the data dictionary where you can view the tables that reference CI_SEAS_TM_SHIFT.
All time sensitive data will be stored according to the base Time Zone defined on the installation record. The time zone table is used to define other time zones and their relation to the base time zone. When data being entered into the system is related to a time zone other than that defined on the installation record, the table may be used by integration / interface logic to convert the data into the base time zone for storage on the database.
Open Admin Menu, Time Zone to define the time zones and their relation to the base time.
Description of Page
Enter a unique Time Zone and Description for the time zone.
Indicate the Shift in Minutes that this time zone differs from the base time zone defined on the Installation Options.
Indicate the Seasonal Time Shift applicable for this time zone.
Where Used
Follow this link to open the data dictionary where you can view the tables that reference CI_TIME_ZONE.
If your company uses geographic coordinates for dispatching or geographic information system integration, you need to setup a geographic (coordinate) type for each type of geographic coordinate you capture on your premises and/or service points (geographic coordinates can be defined on both premises and service points).
To define geographic types, open Admin Menu, Geographic Type.
Find a customer / premise using a geographic coordinate. In Oracle Utilities Customer Care and Billing there are several queries that allow you to search for customers and premises by geographic type. For example, Control Central and Meter Search allow you to search using the premise or service point geographic type. Refer to the product documentation for more information.
Description of Page
Enter an easily recognizable Geographic Type code and Description.
Define the algorithm used to validate the Validation Format Algorithm. If an algorithm is specified, the system will validate that the geographic location entered on the premise and/or service point for the geographic type is in the format as defined in the algorithm. If you require validation, you must set up this algorithm in the system.
Click here to see the algorithm types available for this plug-in spot.
Where Used
Follow this link to open the data dictionary where you can view the tables that reference CI_GEO_TYPE.
Workday calendars are used to ensure system-calculated dates fall on a workday. Select Admin Menu, Work Calendar to define a workday calendar.
Description of Page
The information on this transaction is used to define the days of the week on which your organization works.
Enter a unique Work Calendar and Description.
Turn on (check) the days of the week that are considered normal business days for your organization.
Use the collection to define the Holiday Date and Holiday Name for each company holiday.
Where Used
Follow this link to open the data dictionary where you can view the tables that reference CI_CAL_WORK.
When you set up your users, you reference a display profile. A user's display profile controls how dates, times, and numbers displayed. Choose Admin Menu, Display Profile to maintain display profiles.
Description of Page
Enter a unique Display Profile ID and Description to identify the profile.
Enter a Date Format. This affects how users view dates and how entered dates are parsed. This is a “free format” field with some rules.
· dd or d is interpreted as the day of the month. The d option suppresses a leading 0.
· MM or M is interpreted as the month number. The M option suppresses a leading 0.
· yyyy, yy, or y is interpreted as the year. The year can be 4 or 2 digits. The y option allows entry in either 2 or 4-digit form and is displayed in 2-digit form.
For centuries, the default pivot for 2-digit years is 80. Entry of a 2-digit year greater than or equal to 80 results in the year being interpreted as 19xx. Entry of a 2-digit year less than 80 results in the year being interpreted as 20xx.
· tttt is interpreted as a year entered and displayed in Taiwanese format where 1911 is considered year 0000. Note that the year is still stored in the database in Roman format. For example, if a date in the database is 01-01-2005, it is displayed as 01-01-0094. If a user enters the date 02-02-0095, it is stored in the database as 02-02-2006.
· Other characters are displayed as entered. Typically, these other characters should be separators, such as “-“, “.”, or “/”. Separators are optional; a blank space cannot be use.
Here are some examples of date formats.
|
Format |
Displayed / entered as |
|
MM-dd-yyyy |
04-09-2001 |
|
d/M/yyyy |
9/4/2001 |
|
yy.MM.dd |
01.04.09 |
|
MM-dd-y |
04-09-01 – in this case you could also enter the date as 04-09-2001 |
Enter a Time Format. This is a “free format” display with some rules.
· hh or h is interpreted as the hour, 1-12; KK or K is interpreted as the hour, 0-11; HH or H is interpreted as the hour, 0-23; kk or k is interpreted as the hour, 1-24. The h, K, H, and k options suppress a leading 0.
· mm or m is interpreted as the minutes. The m option suppresses a leading 0.
· ss or s is interpreted as the seconds. The s option suppresses a leading 0.
· a is interpreted to mean display am or pm (only needed when the hour is entered in hh, h, KK or K formats). If an am or pm is not entered, it defaults to am.
Here are some examples of time formats.
|
Format |
Displayed / entered as |
|
hh:mma |
09:34PM (can be entered as 09:34p) |
|
hh:mm:ss |
21:34:00 |
|
h:m:s |
9:34:0 |
There are several options for displaying Numbers. Select the character you use as the Decimal Symbol (“.” or “,”), the symbol that separates the integer and decimal parts of a number. Select the character you use as the Group Symbol (“,”, “.”, None or Space), i.e., the symbol used to separate 1000s. Select an option for the Negative Format, which dictates how negative values are displayed: ‑9.9, (9.9), or 9.9-.
Currency values can have a different Negative Format from other numbers: -s9.9, (s9.9), or s9.9-, where the “s” represents the currency symbol.
Where Used
Follow this link to open the data dictionary where you can view the tables that reference CI_DISP_PROF.
Phone types define the format for entering and displaying phone numbers.
To add or review phone types, choose Admin Menu, Phone Type.
Description of Page
Enter a unique Phone Type and Description for each type of phone number you support.
Select an appropriate Phone Number Format Algorithm for each Phone Type. This algorithm controls the format for entry and display of phone numbers. Click here to see the algorithm types available for this plug-in spot.
Use Phone Type Flag to define if this type of phone number is a Fax number. Defining which phone type is used for facsimile transmittal is only pertinent if your product supports routing of information via fax. For example, in Oracle Utilities Customer Care and Billing, the system may be configured to fax a bill to a customer.
Where Used
Follow this link to open the data dictionary where you can view the tables that reference CI_PHONE_TYPE.
If you need to introduce additional fields to objects that were delivered with minimal fields, you can add a characteristic type for each field you want to capture. Using the characteristic type approach allows you to add new fields to objects without changing the database or the pages.
The topics in this section describe how to setup a characteristic type.
Contents
There Are Four Types Of Characteristics
Searching By Characteristic Values
Characteristic Type - Characteristic Entities
Every characteristic referenced on an object references a characteristic type. The characteristic type controls the validity of the information entered by a user when they enter the characteristic’s values. For example, if you have a characteristic type on a premise in Oracle Utilities Customer Care and Billing called “tax jurisdiction”, the information you setup on this characteristic type controls the valid values that may be specified by a user when the define a premise’s tax jurisdiction.
When you setup a characteristic type, you must classify it as one of the following categories:
· Predefined value. When you setup a characteristic of this type, you define the individual valid values that may be entered by a user. A good example of such a characteristic type would be one used on an account to define the number of days between an account’s bill date and its due date. The valid values for this characteristic type would be defined in a discreet list (because you probably won’t let a user pick any number).
· Ad hoc value. Characteristics of this type do not have their valid values defined in a discreet list because the possible values are infinite. Good examples of such a characteristic type would be ones used to define a person’s birth date or their mother’s maiden name. Optionally, you can plug-in an algorithm on such a characteristic type to validate the value entered by the user. For example, you can plug-in an algorithm on a characteristic type to ensure the value entered is a date.
· Foreign key value. Characteristics of this type have their valid values defined in another table. For example perhaps you want to link a user to a table where User is not already a foreign key. Valid values for this type of characteristic would be defined on the user table. Please be aware of the following in respect of characteristics of this type:
· Before you can create a characteristic of this type, information about the table that contains the valid values must be defined on the foreign key reference table.
· The referenced table does not have to be a table within the system. For example, in Oracle Utilities Customer Care and Billing you may want to create a table that contains valid township codes and reference the appropriate code when you setup a new premise.
· Not all entities that support characteristics support foreign key characteristics. Refer to the data dictionary to identify the entities that include the foreign key characteristic columns.
· File Location. Characteristics of this type contain a URL. The URL can point to a file or any web site. Characteristics of this type might be useful to hold references to documentation / images associated with a given entity. For example, the image of a letter sent to you by one of your customers could be referenced as a file location characteristic on a customer contact entry. When such a characteristic is defined on an entity, a button can be used to open the URL in a separate browser window.
For certain entities in the system that have characteristics, you may search for a record linked to a given characteristic value by entering a characteristic type and value in a related search window.
Not all entities that support characteristics support searching by characteristics. Refer to the data dictionary to identify the characteristic collections that include the search characteristic column.
Warning! For ad-hoc characteristics, only the first 60 bytes are searchable. For foreign key characteristics, only the first column in the foreign key is searchable.
You can restrict the characteristic types that can be used to search for an entity. For example, assume you use a workflow process to upload premise information and “taxing jurisdiction” is one of the characteristics linked to the workflow process. If your company operates entirely within one taxing jurisdiction, you wouldn’t want to allow searching for a workflow process by taxing jurisdiction, as every workflow process would be returned.
A flag on the characteristic type allows an administrator to indicate if searching by this characteristic type is allowed or not allowed.
To define a characteristic type, open Admin Menu, Characteristic Type.
Description of Page
Enter an easily recognizable Characteristic Type and Description for the characteristic type. Ownerindicates if this characteristic type is owned by the base package or by your implementation (Customer Modification).
Important! If you introduce a new characteristic type, carefully consider its naming convention. Refer to System Data Naming Convention for more information.
Use Type of Char Value to classify this characteristic type using one of the following options (refer to There Are Four Types Of Characteristics for more information):
· Predefined value. Characteristics of this type have their valid values defined in the Characteristic Value scroll, below. For each valid value, enter an easily recognizable Characteristic Value and Description. For example, if you introduce a characteristic type to record the number of volts that are measured by a meter, you would add values for all voltage levels measured by the meters utilized by your organization.
· Ad hoc value. Characteristics of this type have an unlimited number of valid values. For example, if you use a characteristic to define the date a meter was ordered, you’d use this classification because you can’t define every possible order date. If you use this option, you can optionally define the Validation Rule used to validate the user-entered characteristic value. For example, if we carry on with our example, you’d use a validation rule to make sure that what the user entered was actually a date. Click here to see the algorithm types available for this plug-in spot.
· File location value. Characteristics of this type contain a URL. The URL can point to a file or any web site. Characteristics of this type might be useful to hold documentation / images associated with a given entity. For example, the image of the formal contract signed by a customer could be referenced as a file location characteristic on a service agreement. When such a characteristic value is defined on an entity, the value is suffixed with a button that can be used to display the URL in a separate browser window.
Note. File location characteristic values must be entered in a “non-relative” format. For example, if you want to define a characteristic value of www.msn.com, you’d enter the characteristic value as http://www.msn.com. If you just enter www.msn.com, the system will suffix the characteristic value to the current URL in your browser and attempt to navigate to this location when the launch button is pressed (this may or may not be the desired result).
· Foreign key reference. Characteristics of this type have their valid values defined in another table. A good example of such a characteristic type would be one used on a premise to define the premise’s building manager. Valid values for this type of characteristic would be defined on the person table (as you’d set up a person for the building manager and then reference this person on the premise characteristic). If you choose this option, you must use FK Reference to define the table that controls the valid values of this characteristic type. Refer to Setting Up Foreign Key References for more information.
Use the Allow Search by Char Val to indicate if searching for an entity by this characteristic type is Allowed or Not Allowed. Refer to Searching by Characteristic Valuesfor more information.
Where Used
Follow this link to open the data dictionary where you can view the tables that reference CI_CHAR_TYPE.
To define the entities (objects) on which a given characteristic type can be defined, open Admin Menu, Characteristic Type and navigate to the Characteristic Entities tab.
Description of Page
Use the Characteristic Entity collection to define the entities on which the characteristic type can be used. Ownerindicates if this is owned by the base package or by your implementation (Customer Modification).
Note. The values for this field are customizable using the Lookup table. This field name is CHAR_ENTITY_FLG.
Heads up. For many entities in the system, the valid characteristics for a record are defined on a related “type” entity. For example, in Oracle Utilities Customer Care and Billing the meter type defines valid characteristics for meters of that type. When configuring your system, in addition to defining the appropriate entity for a characteristic type, you may also need to link the characteristic type to an appropriate entity “type”.
A Foreign Key Reference defines the necessary information needed to reference an entity in certain table.
You need to set up this control table if you need to validate a foreign key value against a corresponding table. For example, if a schema element is associated with an FK Reference the system validates the element’s value against the corresponding table. Refer to Configuration Tools to learn more about schema-based objects. Another example is characteristics whose valid values are defined in another table (i.e., you use “foreign key reference” characteristic types). Refer to There Are Four Types Of Characteristics for a description of characteristics of this type.
A FK Reference is used not just for validation purposes. It also used to display the standard information description of the reference entity as well as provide navigation information to its maintenance transaction. Info descriptions appear throughout the UI, for example, whenever an account is displayed on a page, a description of the account appears.
The above is possible as a result of information you define when you set up a foreign key reference for the table in question. The following points describe what you should know before you can setup a foreign key reference for a table.
· The physical name of the table. Typically this is the primary table of a maintenance object.
· The program used by default to construct the referenced entity’s info description. Refer to Information Description Is Dynamically Derived for more information on how this is used.
· The transaction used to maintain the referenced entity. This is where the user navigates to when using the “go to” button or hyperlink associated with the entity. Refer to Navigation Information Is Dynamically Derived for more information on how this is used.
· The name of the search page used to look for a valid entity. The system launches the search when a user presses the search button that suffixes the characteristic value or column reference value. Typically, this will be the same search page that’s invoked from the table’s maintenance page.
Contents
Information Description Is Dynamically Derived
Navigation Information Is Dynamically Derived
Typically a FK Reference is defined for a maintenance object’s primary table. In this case the system dynamically derives the standard information associated with a specific referenced entity as follows:
· Attempt to determine the business object associated with the referenced entity. Refer to the Determine BO maintenance object algorithm system event for more information. If a business object has been determined, the system lets the business object’s Information plug-in, if any, format the description.
· If a business object has not been determined or the business object has no such plug-in, the system lets the maintenance object’s information plug-in, if any, format the description.
· If the maintenance object has no such plug-in, the system uses the info program specified on the FK Reference to format the description.
Technical note. For both Java and COBOL, the class / program that returns the information displayed adjacent to the referenced entity is generated specifically for use as an info routine. Please speak to your support group if you need to generate such a class / program.
Generic routine. The system provides a generic information routine that returns the description of control table objects from its associated language table. By "control table" we mean a table with an associated language table that contains a DESCR field. Refer to Defining Table Options for more information on tables and fields. For COBOL, the name of the generic routine is Get Description Info. For Java, the java class is com.splwg.base.domain.common.foreignKeyReference.DescriptionRetriever.
Typically a FK Reference is defined for a maintenance object’s primary table. In this case the system dynamically derives the actual transaction to navigate to for a given referenced entity as follows:
· Attempt to determine the business object associated with the referenced entity. Refer to the Determine BO maintenance object algorithm system event for more information. If a business object has been determined, use the maintenance portal defined as its Portal Navigation Option business object option.
· If a business object has not been determined or the business object defines no such option, the system uses the transaction specified on the FK Reference.
To setup a foreign key reference, open Admin, Foreign Key Reference.
Important! If you introduce a new foreign key reference, carefully consider its naming convention. Refer to System Data Naming Convention for more information.
Description of Page
Enter an easily recognizable FK (foreign key) Reference code and Description for the table.
Enter the name of the Table whose primary key is referenced. After selecting a Table, the columns in the table’s primary key are displayed adjacent to Table PK Sequence.
Use Navigation Option to define the page to which the user will be transferred when they press the go to button or hyperlink associated with the referenced entity. Refer to Navigation Information Is Dynamically Derived for more information on how this is used.
The Info Program Type indicates whether the default program that returns the standard information description is written in COBOL or Java.
· If the Program Type is COBOL, use Info Program Name to enter the name of the COBOL program.
· If the Program Type is Java, use Info Program Name to enter the Java class name.
Refer to Information Description Is Dynamically Derived for more information on the info program is used.
COBOL Programs. COBOL programs are only supported as part of Oracle Utilities Customer Care and Billing.
View the source. If the program is shipped with the base package, you can use the adjacent button to display the source code of this program in the source viewer or Java docs viewer.
Use Context Menu Name to specify the context menu that appears to the left of the value.
Use Search Navigation Key to define the search page that will be opened when a user searches for valid values. This is only applicable for characteristics and column references.
Use Search Type to define the default set of search criteria used by the Search Navigation Key's search page.
Use Search Tooltip to define a label that describes the Search Navigation Key's search page.
Context Menu Name, Search Type and Search Tooltip. These attributes are only applicable to user interface elements utilizing the foreign key compound element type. Report parameters that reference foreign key characteristics are an example.
Where Used
Follow this link to open the data dictionary where you can view the tables that reference CI_FK_REF.
A limited number of the system's features are configured by populating options on a "feature configuration". For example, if your implementation uses Oracle Utilities Customer Care and Billing's batch scheduler, you must populate a variety of options on the batch scheduler's feature configuration.
The administration documentation for each feature defines the impact of each option. The topics below simply describe how to use this transaction in a generic way.
You can create features to control features that you develop for your implementation. To do this:
· Define the new feature. You do this by adding a new lookup value to the EXT_SYS_TYP_FLG lookup field.
· Define the feature's options. You do this by creating a new lookup field. The field must be in the format xxxx_OPT_TYP_FLG where xxxx is the identifier of the EXT_SYS_TYP_FLG added above.
· Flush all caches.
Feature Configuration - Messages
To define your feature configuration, open Admin Menu, Feature Configuration.
Description of Page
Enter an easily recognizable Feature Name code.
Indicate the Feature Type for this configuration. For example, if you were setting up the options for the batch scheduler, you'd select Batch Scheduler.
You can add new Feature Types. Refer to the description of the page above for how you can add Feature Types to control features developed for your implementation.
Multiple Feature Configurations for a Feature Type. Some Feature Types allow multiple feature configurations. The administration documentation for each feature will tell you when this is possible.
The Options grid allows you to configure the feature. To do this, select the Option Type and define its Value. Set the Sequence to 1 unless the option may have more than value. Detailed Description may display additional information on the option type.
Each option is documented elsewhere. The administration documentation for each feature describes its options and whether an option supports multiple values.
You can add new options to base-package features. Your implementation may want to add additional options to one of the base-package's feature types. For example, your implementation may have plug-in driven logic that would benefit from a new option. To do this, display the lookup field that holds the desired feature's options. The lookup field's name is xxxx_OPT_TYP_FLG where xxxx is the identifier of the feature on the EXT_SYS_TYP_FLG lookup value. For example, to add new batch scheduler options, display the lookup field BS_OPT_TYP_FLG.
If the feature exists to interface with an external system, you can use this page to define the mapping between error and warning codes in the external system and our system.
Open this page using Admin Menu, Feature Configuration and navigate to the Messages tab.
Description of Page
For each message that may be received from an external system, define the Feature Message Category and Feature Message Code to identify the message.
A corresponding message must be defined in the system message tables. For each message identify the Message Category and Message Number. For each new message, the Message Category defaults to 90000 (because an implementation's messages should be added into this category or greater so as to avoid collisions during upgrades).
A master configuration enables an implementation to capture various types of information in the system. For example, a master configuration exists in the base product that captures the mapping between Hijri and Gregorian dates. Given this, users are able to switch between Gregorian and Hijri date formats by changing the display profile on their user record.
Master Configurations can be bundled for export to other environments.
To set up a master configuration, open Admin Menu, Master Configuration.
The topics in this section describe the base-package zones that appear on the Master Configuration portal.
Contents
The Master Configuration List zone lists every category of master configuration. The following functions are available:
· Click a broadcast button to open other zones that contain more information about the adjacent master configuration.
· Click the Add/Edit button to start a business process that updates the master configuration.
The Master Configuration Details zone contains display-only information about a master configuration. This zone appears when a master configuration has been broadcast from the Master Configuration zone.
Please see the zone's help text for information about this zone's fields.
The following sections describe miscellaneous system wide topics.
Contents
The system provides the ability to simplify the user interface based on functionality areas practiced by your organization.
Menu items and other user interface elements are associated with function modules. By default, all function modules are accessible. If a function module is not applicable to your business you may turn it off. Refer to Turn Off A Function Module for more information on how to turn off a module.
If a function module is made non-accessible, i.e. turned off, its related elements are suppressed from the user interface. In addition the system may validate that related functionality is not accessed. This also means that turning off the wrong module may cause any of the following to occur:
· Menu items may not appear. Refer to Menu Item Suppression to better understand how menu item suppression works.
· Entire menus may not appear. Refer to Menu Suppression to better understand how menu suppression works.
· Tabs on pages may not appear.
· Fields may not appear.
· The system may return an error message when you attempt to use a function (indicating the function is turned off).
To correct the above situation, simply remove the module from the turned off list thus making it accessible again.
Your module configuration setup is displayed on the installations record.
Contents
The following points describe how your module configuration can suppress menu items.
· Menu items that are owned by the base product (as opposed to those your implementation adds) are associated with one or more function modules. If your module configuration has turned off all of the menu item's modules, the menu item is suppressed. If at least one of the modules is accessible, i.e. turned on, the menu item is not suppressed.
· If a menu line doesn't contain any accessible items, the menu line is suppressed.
· If all lines on a menu are suppressed, the menu is suppressed when the menu button is clicked.
In addition to the above Menu Item Suppression logic, the following points describe how your module configuration can suppress an entire menu.
· Menus that are owned by the base product (as opposed to those your implementation adds) are associated with one or more function modules.
· If your module configuration has turned off all of the menu's modules, the entire menu is suppressed. If at least one of the modules is accessible, i.e. turned on, the menu s not suppressed.
The base package is provided with a Module Configuration Feature Configuration that allows your organization to turn off base package function modules.
To turn off any of the base package function modules add a Turned Off option to this feature configuration referencing that module. Refer to the MODULE_FLG lookup field for the complete list of the application's function modules.
Any module not referenced on this feature configuration is considered turned on, i.e. accessible. To turn on a module, simply remove its corresponding Turned Off option from this feature configuration.
You may view your module configuration setup on the installation options page.
Only one. The system expects only one Module Configuration feature configuration to be defined.
The framework web application provides each product the ability to nominate certain fields to act as a “global context” within the web application. These fields are known as global context fields. For example, in Oracle Utilities Customer Care and Billing, the global context fields are typically Account ID, Person ID and Premise ID. The values of these fields may be populated as a result of searching or displaying objects that use these fields in their keys. If you navigate to the Bill page and display a bill, the global context is refreshed with the Account ID associated with that bill. The global context for Person ID and Premise ID are refreshed with data associated with that account.
Changing the values of the global context typically cause data displayed in zones on the dashboard to be refreshed to show information relevant to the current values of these global context fields.
When the value of one of the global context fields changes, an algorithm plugged into the installation record is responsible for populating the remaining global context values accordingly. Refer to your specific product for more information about the base algorithm that is provided for that product.
Customer modification. If the global context values provided by your product do not satisfy your implementation's business requirements, contact customer support for information on how to customize the global context information.
There are several maintenance objects in the system that include owner flag in one or more if its tables. We refer to the data in these tables as "system data". Some examples of system data tables include Algorithm Type, Batch Control, Business Object and Script. Implementations may introduce records to the same tables. The owner flag for records created by an implementation is set to CM (for customer modification), however the owner flag is not part of the primary key for any of the system data tables. As a result, the base product provides the following guidelines for defining the primary key in system data tables to avoid any naming conflict.
Contents
For any table that includes the owner flag, the base product will follow a naming convention for any new data that is owned by the base product. The primary key for records introduced by the product is prefixed with x1- where x1 is the value of the owner flag. For example, if a new background process is introduced to the framework product, the batch code name is prefixed with F1-.
Note. There are some cases where the hyphen is not included.
Please note that this standard is followed for all new records introduced by the base product. However, there are base product entries in many of these system data tables that were introduced before the naming convention was adopted. That data does not follow the naming convention described above.
When new system data is introduced for your implementation you must consider the naming convention for the primary key. The product recommends prefixing records with CM, which is the value of the owner flag in your environment. This is consistent with the base product naming convention. This convention allows your implementation to use the CM packaging tool in the Software Development Kit as delivered. The extract file provided with the tool selects system data records with an owner flag of CM AND with a CM prefix.
Note. If you choose not to follow the CM naming convention for your records and you want to use the CM packaging tool, your implementation must customize the extract file to define the appropriate selection criteria for the records to be included in the package. Refer to the Software Development Kit documentation for more information.
Also note that owner flag may be introduced to an existing table in a new release. When this happens, the CM packaging tool is also updated to include these new system data tables. Your implementation will have existing records in those tables that probably do not follow any naming convention. After an upgrade to such a release, if you want to include this data in the CM packaging tool, you must customize the extract file for the tables in question.
A great deal of information in the system changes infrequently. In order to avoid accessing the database every time this type of information is required by an end-user, the system maintains a cache of static information on the web server. In addition to the web server’s cache, information is also cached on each user’s browser.
Contents
The cache is populated the first time any user accesses a page that contains cached information. For example, consider a control table whose contents appear in a dropdown on various pages. When a user opens one of these pages, the system verifies that the list of records exists in the cache. If so, it uses the values in the cache. If not, it accesses the database to retrieve the records and saves them in the cache. In other words, the records for this control table are put into the cache the first time they are used by any user. The next user who opens one of these pages will have the records for this control table retrieved from the cache (thus obviating the database access).
The following points describe the type of data that is cached on the web server:
· Field labels. This portion of the cache contains the labels that prefix fields on the various pages in the system.
· System information. This portion of the cache contains installation and basic information about the various application services (e.g., the URL’s that are associated with the various pages).
· Menu items. This portion of the cache contains the menu items.
· Dropdown contents. This portion of the cache contains the contents of the various dropdowns that appear throughout the system.
· XSL documents. This portion of the cache contains each page’s static HTML.
· Portal information. This portion of the cache contains information about which zones are shown on the various pages.
The contents of the cache are cleared whenever the web server is “bounced”. This means that fresh values are retrieved from the database after the application server software is restarted.
If you change the database after the cache is built and the information you changed is kept in the cache, users may continue to see the old values. If you don’t want to bounce your web server, you can issue one of the following commands in your browser’s URL to immediately clear the contents of the cache (a separate command exists for each type of data that is held in the cache):
· flushAll.jsp?language=<language code>. This command flushes every cache described below.
· flushMessageCatalog.jsp. This command flushes the field labels. Use this whenever you add or change any labels (this is typically only done by implementers who have rights to introduce new pages).
· flushSystemLoginInfo.jsp. This command flushes the system information cache. Use this whenever you change navigation options, cached information from the installation record, or if you change an application service’s URL.
· flushMenu.jsp. This command flushes the menu cache. Use this command if you change menu data.
· flushDropdownCache.jsp?language=<language code>. This command flushes ALL objects in the dropdown contents associated with a given language (note, the language code is defined on the Language control table). Use this whenever you change, add or delete values to/from control tables that appear in dropdowns. Unlike the above caches, the objects in the dropdown cache are flushed automatically every 30 minutes from the time they are first built.
· flushDropDownField.jsp?language=<language code>&key=<field>. If you want to flush the values in a specific drop-down field in the cache, specify the <field> using this command.
· flushUI_XSLs.jsp. This command flushes the XSL document cache. Use this command if you change user interface meta-data. Also use this command whenever you change or introduce new zones.
· flushXMLMetaInfo.jsp. This command flushes the XML repository of the XML Application Interface. Use this command when your site’s XAI configuration data needs to be updated, which should be a very rare occurrence.
· flushPortalMetaInfo.jsp. This command flushes the portal information cache. Use this command whenever you change any portal zone meta-data.
For example, assume the following:
· the web server and port on which you work is called CD-Production:7500
· you add a new record to a control table and you want it to be available on the appropriate transactions immediately (i.e., you cannot wait for 30 minutes)
You would issue the following command in your browser’s address bar: http://CD-Production:7500/flushDropdownCache.jsp?language=ENG. Notice that the command replaces the typical cis.jsp that appears after the port number (this is because these commands are simply different JSP pages that are being executed on the web server).
In addition to the web server’s cache, information is also cached on each user’s browser. After clearing the cache that’s maintained on the web server, you must also clear the cache that’s maintained on your client’s browser. To do this, follow the following steps:
· Select Tools on your browser’s menu bar
· Select Internet Options … on the menu that appears.
· Click the Delete Files button on the pop-up that appears.
· Turn on Delete all offline content on the subsequent pop-up that appears and then click OK.
· And then enter the standard URL to re-invoke the system.
Automatic refresh of the browser’s cache. Each user’s cache is automatically refreshed based on the maxAge parameter defined in the web.xml document on your webserver. We recommend that you set this parameter to 1 second on development / test environments and 28800 seconds (8 hours) on production environments. Please speak to system support if you need to change this value.
Your implementation team can execute the system using a special mode when they are configuring the application. To enable this mode, enter ?debug=true at the end of the URL that you use to access the application. For example, if the standard URL was http://CD-Production:7500/cis.jsp, you'd enter http://CD-Production:7500/cis.jsp?debug=true to enable configuration mode.
When in this mode certain debugging oriented tools become available right below the main tool bar.
· A Show User Log button appears allowing users to view their own log entries. The number of “tail” entries to view may be specified in the adjacent Log Entries field before clicking the button. Limiting the number of entries to view allows the user to quickly and easily see only the latest log entries without having to manually scroll to the end of the log.
· Checking the Global Debug indication starts various tracing options.
Other parts of the system may show additional configuration oriented icons when in this mode. For example, explorer zones may provide additional tools to assist in debugging zone configuration. These icons are described in the context of where they appear.
Show User Log button is secured. An application service F1USERLOG has been provided for this functionality to allow implementations to restrict user access to this button. Such restriction may be called for in production environments.
The system provides a way to override the system date used for online operations. Under the General System Configuration Feature Configuration, the System Override Date Option Type holds the date the application will use as the system date instead of retrieving the same from the database. This feature can be especially useful in running tests that require the system date to be progressed over a period of time.